Many companies design core circuitry to be integrated by other companies (customers) into the other companies' products. In order for a customer to design its product using a company's core circuitry, the company provides to the customer one or more computer files or modules of resistor transfer logic (RTL) code that describes the core circuitry in a hardware descriptor language (HDL), such as “Verilog” or “VHDL.” (This HDL module(s) will be referred to as the “core.”) The customer then combines the core with HDL modules of its own circuitry to form a computerized model of its end product, or a portion of the product. The customer can then analyze the performance and debug the design of its product in a computerized simulation using the circuit modules.
In order to protect its proprietary designs or intellectual property, the company may encrypt the core. With only an encrypted core, the customer cannot view the actual RTL code. Instead, the customer is also provided with a module known as a “wrapper” that encapsulates all of the requisite inputs and outputs (I/Os) of the core. The circuit modules of the customer's circuitry interact with the wrapper, which interacts with the core.
The customer compiles the core and wrapper along with the customer's circuit modules to form a simulation environment or “test bench.” When the customer runs the simulation, various types of problems or errors may occur requiring troubleshooting or debugging. Some of the most common problems or errors may be a result of a flaw in the design of the customer's circuit modules, a flaw in the design of the company's core or a mistake in the compilation of the core. Once the design flaws are corrected and all of the circuit modules, including the core, are properly compiled, the simulation may indicate that the circuit modules represent or define a useable design for the customer's product.
In the troubleshooting or debugging of the problems or errors that occur during the simulations, the customer can readily examine the circuit modules of its circuitry for any bugs or design flaws. The customer can do so because the customer has the source code for the circuit modules, which are written in the HDL, which is readable and understandable to a person who is well versed in the HDL. However, if the company has provided only an encrypted core (and the wrapper) to the customer, then the customer cannot very well investigate a problem that apparently occurs in the company's core. Instead, the customer may provide proper input stimuli from its circuit modules to the core, but get unknown or wrong output values, and not be able to troubleshoot the problem. Therefore, the customer must work with the company to troubleshoot or debug a problem or error that occurs in the company's core, including to determine whether the customer simply compiled the core improperly, to examine the source code of the core for design flaws, etc.
Since the customer cannot examine the company's core, the customer must inform the company of the problem and allow the company to do part or all of the troubleshooting. To troubleshoot the problem, the company may have to reproduce the problem in its own lab using its own simulator. To reproduce the problem, one of the steps that the company needs to take is to provide the input stimuli to the core in essentially the same manner as did the customer. It is usually the customer's circuit modules that generated the input stimuli for the core during the simulation of the entire environment. However, the customer's circuit modules typically contain valuable proprietary designs or intellectual property, so the customer may not be willing to provide its circuit modules to the company. Therefore, in order for the company to be able to provide the proper input stimuli to its core in the company's simulation environment, the customer usually has to generate a waveform data file of the input stimuli in the customer's simulation environment. The waveform data file is generally a “dump” or “trace” of the waveform of the relevant signals. The company can then simulate the performance of the core using the customer's waveform data file to supply the input stimuli to the core.
There are a variety of different waveform data formats that can be used to generate the waveform data file. For example, the “value change dump” (VCD) file incorporates one such waveform data format, which is specified in the IEEE 1364-1995 standard. The customer's simulator generates the waveform data file in the customer's simulation environment, and the company's simulator reads signal patterns from the waveform data file in the company's simulation environment.
Various difficulties arise when using waveform data files in this manner. For instance, it is usually necessary to pre-process the waveform data file to put it in a useable format, since the company may use a different simulator or simulation environment. Additionally, even for a standard waveform data file, such as the VCD file, the format is not consistent and may not be readily available to the company. For example, different representations may be used to represent the values of buses (e.g. bus representation can be either 8′h00000000 or 8′h0). Furthermore, some customers may use simulators that cannot easily generate a waveform data file. Moreover, some simulations may result in very large waveform data files, which can make pre-processing very time consuming.
It is with respect to these and other considerations that the present invention has evolved.